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We describe a strategy language to control the application of graph rewriting rules, and 
show how this language can be used to write high-level declarative programs in several 
application areas. This language is part of a graph-based programming tool built within the 
port-graph transformation and visualisation environment PORGY. 



1 Introduction 

Rewriting [4] is a computation model used in computer science, algebra, logic and linguistics, 
amongst others. Its purpose is to transform syntactic objects (words, terms, programs, proofs, 
graphs, etc., which we will call generally expressions), by applying rewrite rules until a suitable 
simplied form is obtained. 

Given an expression and a set of rewrite rules, it is often the case that several different rules 
can be applied, and the same rule can be applied to different sub-expressions. To control the 
rewriting process, a strategy of application of rules is used. 

In this paper we focus on graph rewriting |TTll27| . Graphs are widely used for describing 
complex structures in a visual and intuitive way, e.g., UML diagrams, representation of proofs, 
microprocessor design, XML documents, communication networks, data and control flow, neu- 
ral networks, biological systems, etc. Graph rewriting has many applications in specification, 
programming, and simulation tools, amongst others fl2l |l3l . Several graph-transformation 
languages and tools have been developed, such as PROGRES [28J, AGG [14], Fujaba [23], 
GROOVE (26l, GrGen QZ1 and GP (251, only to mention a few. 

When the graphs are large or growing along transformations, or when the number of 
graph rewriting rules is large, visualisation becomes crucial to understand the graph evolution. 
PORGY HI is a visual environment that allows users to define graphs and graph rewriting rules, 
and to experiment with a graph rewriting system in a visual and interactive way. For instance, 
one may want to apply a rule r on a graph G at the positions described by the subgraph P to 
study different rewriting derivations for G. To control the application of graph rewriting rules, 
PORGY uses a strategy language. In this paper we describe this strategy language and show 
how it can be used to write high-level declarative programs in several application areas. 

Strategies for rewriting have been well studied in the case of terms: there are languages that 
allow the user to specify and apply strategies controlling the use of term rewrite rules (see for 
instance |9H29[[6|). For graph rewriting, some of the languages and tools mentioned above also 
allow users to guide the rewriting engine, for instance by specifying the order in which rules will 
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be applied; PROGRESS, Fujaba and GP offer control structures to guide the application of rules. 
PORGY's strategy language draws inspiration from these languages, and also from the strategy 
languages available for term rewriting. A distinctive feature of our strategy language is that it 
allows users to describe not only the rules that need to be applied, but also the location in the 
graph where they apply, and the propagation mechanism controlling successive applications of 
rules (the latter is not trivial in the case of graphs, since there is no notion of a root, so standard 
term rewriting strategies based on top-down or bottom-up traversals do not make sense in this 
setting). 

The syntax of PORGY's strategy language includes constructs to update the positions where 
rewriting rules can apply, and to specify the way rules should be applied. After giving the syntax 
of the language, and a short, informal description of its semantics, in this paper we show how the 
language can be used to write numerical programs, geometric applications where visualisation 
plays an important role (we give a program to draw a Von Koch fractal), and also applications 
to game design. 

Summarising, in this paper we describe a language to define graph rewriting systems and 
strategies to control the application of rules. Programs in this language operate on graphs, 
which are transformed by application of rules at positions described explicitly in the program. 
We give examples to illustrate the features of the language, and in particular we show how the 
ability to control not only the rules and sequences of rules to be applied but also the location in 
the graph where rules are applied, allows programmers to write concise, visual programs, in 
several application areas. 

In a companion paper [15 1 we give the formal semantics of the language. For more details 
about the PORGY tool for graph visualisation and transformation, for which the strategy 
language was developed, we refer the reader to (l). 

The paper is organised as follows: In Section [2] we give a short overview of the graph 
rewriting formalisms used in this paper. We describe the strategy language in Section [3] and 
show applications in Section [4] In Section [5] we discuss related work. Section [6] concludes and 
gives some directions for future work. 



2 Background 

A graph rewriting system is a set of rewrite rules of the form L => R where L and R are graphs. 
Such a rule applies to a graph G if G contains at least one instance of the left-hand side L, i.e. a 
subgraph A isomorphic to L. Each rule specifies an interface that is used in order to rewrite A 
in G: G rewrites to a new graph G' obtained by replacing the instance A of L by an instance B of 
R, where edges that were connected to nodes in A are connected to B as specified by the rule's 
interface. This rewriting process induces a transitive relation on graphs. Each rule application 
is a rewriting step and a derivation is a sequence of rewriting steps, that we will sometimes call 
a computation, referring to application of rewriting to programming languages. 

There are several formal definitions of graph rewriting systems, depending on the kind of 
graphs and rewriting rules that can be defined in the system (see, for instance, ||7ll24ll8l [T9l ). As 
a particular example of graph rewriting formalism of interest, in this paper we consider port 
graph rewriting, of which interaction nets ||T9ll are a particular case. We recall below the main 
notions of port graph rewriting, and refer to [2] for more details. 
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Port graphs. A port graph [3|| is a graph where nodes have explicit connection points called 
ports and the edges are attached to specific ports of nodes. Each edge connects at most two 
ports. Nodes and ports are labelled using j¥ and & ', which are two disjoint sets of node names 
and port names respectively. A p-signature over jV and is a mapping V : Jf -» 2^ which 
associates a set of port names to a node name. Without loss of generality, we assume that the 
port names associated to different node names are different. In addition, ports may have state 
information, which is formalised using a mapping from port names to port states. 

Let G and H be two port graphs over the same p-signature. A port graph morphism f : G — > H 
maps elements of G to elements of H preserving sources and targets of edges, as well as node 
names and associated port name sets. 

A port graph rewrite rule L => R is itself represented as a port graph consisting of two port 
graphs L and R over the same p-signature and one special node =>, called arrow node connecting 
them. L and R are called the left- and right-hand side respectively. The arrow node is used to 
specify the correspondence between free ports in the left- and righ-hand sides of the rules, i.e., 
the interface of the rule. For each port p in L to which corresponds a non-empty set of ports 
{pi,...,p n } in R, the arrow node has a unique port r and the incident directed edges (p,r) and 
(r,pi), for all i = l,...,n; all ports from L that are deleted in R are connected to the black hole port 
of the arrow node. When the correspondence between the ports in the left- and right-hand 
sides is obvious we omit the ports and edges involving the arrow node. 

We illustrate the notions of port graph and port graph rewriting rule with examples in 
Section |U 

Let L => R be a port graph rewrite rule and G a port graph such that there is an injective 
port graph morphism g from L to G; hence g(L) is a subgraph of G. Replacing g(L) by g(R) and 
connecting it with the rest of the graph as specified by the interface of the rule, we obtain a 
port graph G' which represents a result of one-step rewriting of G using the rule L => R, written 
G — >l=>r G' . There may be different injective morphisms g from L to G; they are built as solutions 
of a matching problem from L to a subgraph of G. If there is none, we say that G is irreducible 
by L => R. Given a finite set of rules, a port graph G rewrites to G', denoted by G — G', if 
there is a rule r in % such that G — > r G'. This induces a transitive relation on port graphs. Each 
rule application is a rewriting step and a derivation, or computation, is a sequence of rewriting 
steps. A port graph on which no rule is applicable is in normal form. Rewriting is intrinsically 
non-deterministic since it may be possible to rewrite several subgraphs of a port graph at the 
same time with different rules or the same one at different places, possibly getting different 
results. 

Interaction nets. Interaction nets were introduced by Lafont in 1990 |1T91| and later used as a 
target language for implementation of efficient A-calculus evaluators (see for instance [|T8ll2T| V 

A system of interaction nets is specified by a set E of symbols with fixed arities, and a set fl 
of interaction rules. An occurrence of a symbol a e E is called an agent. If the arity of a is n, then 
the agent has n + 1 ports: a principal port depicted by an arrow, and n auxiliary ports. Figure [TJa) 
shows a typical drawing of such an agent. Intuitively, a net N is a port graph (not necessarily 
connected) where the nodes are agents. The ports that are not connected to another agent are 
said to be free. The interface of a net is its set of free ports. 

Interaction rules are port graph rewrite rules where the left-hand side consits of two agents 
(a,jS) e E x E connected together on their principal ports (an active pair or redex) and the right- 
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hand side is a net N with the same number of free ports as the left-hand side. In addition, at 
most one rule can be given for each pair of agents. The diagram depicted in Fig.JTpb) shows the 
format of interaction rules (N can be any net built from E). 

Interaction rules can be seen as a particular kind of port graph rewriting rules with con- 
straints that ensure good computational properties: pattern-matching is particularly easy in 
interaction nets, since patterns are graphs containing just two nodes, and the transformations 
are local and strongly confluent. 

In some contexts, for instance when using interaction rules to program functions, we need 
a weaker notion of normal form corresponding to the notion of weak head normal form in 
A-calculus. Interface normal form, defined in [16 1, can be computed by a strategy which applies 
rules at the interface (if possible) in order to minimise the length of the reduction sequence. We 
give examples below. 

3 Strategy language 

Since the application order of a set of port graph rewrite rules on a port graph may alter the 
result and the resources (e.g., time and space) needed to reach the result, a rewriting strategy is 
needed to control the rewriting process. As mentioned in the introduction, strategic rewriting 
has been well studied for term rewriting systems (see, e.g., [lOl l29l |6)). Here we present a 
strategy language for graph rewriting systems, where strategies take into account rule selection 
and position selection in a graph. 

The notion of position in a graph is rather delicate since there is no notion of root. Hence 
standard term rewriting strategies based on top-down or bottom-up traversals do not make 
sense in the case of graphs. A specific language is needed to define strategies for graph rewriting 
systems. We propose a strategy language where expressions include operators to select rules 
and the positions where the rules are applied, and also to change the positions along the 
derivation. 

Let G be the graph to be rewritten. Then a position P is a subgraph of G specifying where 
rewrite rules are allowed to apply. More precisely, we require that the homomorphic image of 
the left-hand side of the rule (L => R) has a non-empty intersection with this subgraph, that is at 
least one node in g(L) is in P. A simple and intuitive example is to define P to be a specific node 
and in this case, only the rules having this node in the homomorphic image of their left-hand 




(a) Agent 



(b) Interaction rule 



Figure 1: General format of an agent and an interaction rule 
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Let G: Graph, P:Position, p:Property, m,n:Int 
CrtPos | AllSuc | OneSuc \ NextSuc \ SetPos(P) 



Transformation) 



Property(p,G) \TUT\ TnT\ T\ T-T 

Id | Fail | (Li => K,) P | A \\ A \ A \\\ A \ A^"'^ 

T\A \ S;S \ S + S\ ppick(S,...,S) 

while (S) do (S) min(m) max(n) 

if (S) then(S) else(S) \ PnotEmpty \ (S) 



(Application) 
(Strategy) 



A 



S 



Figure 2: Syntax of the strategy language. 



sides are allowed to apply. 

We call the structure G[P] consisting of a graph and a position a located graph. A program is 
composed of a located graph and a strategy expression. Programs act on graphs; the result of a 
terminating program is a new graph. 

The syntax of the strategy language is given in Figure [2j where we show the grammars S, A 
and T for generating strategy expressions, rule applications and position transformations, respectively. 
The main idea is that given a set of graph rewrite rules, an initial located graph and a strategy 
expression in this language, rewriting sequences (i.e., derivations) are generated, starting from 
the initial graph, by applying the rules as specified by the strategy expression. The most 
basic expressions generated by the grammar are Id and Fail, namely identity and failure. A 
position transformation (see the grammar for T in Figure [2j applied on a located graph G[P] 
only affects the subgraph specifying the positions (i.e., P). An application (see the grammar for 
A in Figure [2j on a located graph may change both the graph and the positions. A strategy 
expression embeds the previous constructs and combines them using sequential composition, 
iteration and conditional choice (see the grammar for S in Figure [2]). Below we describe the 
constructs of the strategy language and their effect on a given located graph; we finish this 
section with some examples. 

Position transformations. These allow programmers to focus on different parts of the graph 
during the rewriting process. A position transformation T applies to a located graph G[P] to 
produce a new graph G[P']. The new position P' computed by T is defined as follows. CrtPos 
returns the current position in the located graph (it is akin to the identity transformation). AllSuc 
returns immediate successors of all nodes of P, where an immediate successor of a node A is 
a node that has a port connected to a port of A. OneSuc looks for all the immediate successors 
of all nodes in P and picks one of those randomly. NextSuc computes successors of nodes in P 
using a designated port for each node (for Interaction Nets, this is the principal port). SetPos(P') 
changes the position P to P' , where P' is a subgraph of G explicitly defined (for instance by 
selecting nodes through PORGY's visual interface). Property(p,G') updates P to contain only 
the nodes from the graph G' that satisfy the property p (G' will generally be the given located 
graph or the subgraph P). The set theory operators union, intersection, complement and subtraction 
apply to positions since they are graphs considered as sets of nodes and edges. 

Applications. The application of Id never fails and leaves the graph unchanged whereas Fail 
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always fails (it leaves the graph unchanged and returns failure). (L => R)m represents the 
application of the rule L => R in G[P] if L nP is not empty (i.e., the graph reduced must overlap 
with the position P specified in the located graph); M is the subgraph of R that is added to 
position P (in the copy of R added to G in the rewrite step, the nodes in M become part of P; 
the rest of R is only added to G and not to P). A \\ A' represents simultaneous application of A 
and A' on disjoint subgraphs of G and returns Id only if both applications are possible and Fail 
otherwise. A ||| A' is a weaker version of A \\ A' as it returns Id if at least one application of A or 
A' is possible. A^ m,n ^ applies A simultaneously a minimum of m and a maximum of n times. If 
the minimum is not satisfied then Pail is returned and Id otherwise. If n is a negative integer 
then no maximum is considered. 

Strategies. The expression S;S' represents sequential application of S followed by S', and 
S + S' implements McCarthy's AMB operator [22 J. The strategy ppick(S,S') is a weaker version 
of S + S' as it randomly picks one of the strategies for application. For iterations, we have 
expressions of the form while (S) do(S') min(m) max{n) which keep on sequentially applying S' 
while the expression S evaluates to Id; if the minimum of m successful applications of S' is 
not satisfied then it returns Fail or else Id is returned. Similar to A^ m,n \ setting n to a negative 
integer eliminates the maximum. The strategy if (S) then(S') else(S") checks if the application 
of S to G[P] returns Id in which case S' is applied to G[P] otherwise S" is applied (S is checked 
on a copy of G and not on G itself so the graph is not affected during the checking process). 
PnotEmpty returns Fail if P is empty and Id otherwise. This can be used for instance inside the 
condition of an if or while, to check if the strategy makes P empty or not, instead of checking 
if the strategy itself can be applied. The strategy (S) applies S and considers S as one atomic 
rewriting step in the derivation tree. This is useful to abstract several reduction steps as one for 
visualisation purposes. 

The semantics of the strategy constructs defined by the grammars in Fig.|2]has been formally 
defined in |[T5| using rewrite rules that apply to programs [S,G[P]] where S is a strategy and 
G[P] a located graph. These rewrite rules are governed by a top-down, left-right meta-strategy 
which ensures the following property (we refer the reader to [15] for details and proofs). 

When the strategy S is grammatically correct, an expression [S,G[P]J either rewrites 
indefinitely (when the strategy S does not terminate) or rewrites to an expression of the form 
[E,G'[P']]], where E is Id or Fail and G'[P'] is a new located graph. 

We will now illustrate the strategy language with a few examples. 

Example 1 In many applications, we need to repeatedly apply a rule (or set of rides, or more generally, 
we need to iterate a strategy) as long as possible. This can be easily done in the language by defining the 
expression repeat t (S) as shown below. The expression repeat + (S) applies S at least once. 

• repeat t (S) = while(S) do (S) min(-l) max(-l) 

• repeat + (S) = while(S) do (S) min(l) max(-l) 

More concretely, the following expression can be used if (A — > B) and (C — > D) are two chemical 
reactions that must take place together (represented as graph rewriting rules). 

repeat t ((A => B)\\(C D)) 

Other well-known strategy operators, such as Not, orelse and Try are defined below, together with a 
strategy to compute interface normal forms of interaction nets. 
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• Not(S) = if(S) then(Fail) else(Id) is a strategy that fails ifS succeeds, and conversely, it succeeds 
if S fails. 

• S orelse S' = if(S) then(S) else(S'), applies S if possible, otherwise it applies S' and fails if neither 
strategy is applicable. 

• Try(S) = if(S) then(S) else(Id) is a strategy that behaves like SifS succeeds, but if S fails then it 
behaves like Id. 

• The interface of a graph G is the set of nodes of G that have a free port. They can be selected by 
defining the position Property(interface,G), denoted Int. Then, ifG is an interaction net and P its 
interface, the program \repeatJ^K\,Int)orelse Next),G\P^ computes the Interface Normal Form 
ofG with respect to R\. 

The strategy language described in this section has been implemented into PORGY in the 
form of a plug-in. The user types in a strategy expression which is first parsed by an algorithm 
to create a strategy tree. A strategy engine then takes the tree and applies a series of rewrite 
rules on the tree, following the meta-strategy defined by the formal semantics of the language 
in iri5| . Some of these rules will call for an application or a transformation to be performed on 
the graph. The strategy engine terminates when the tree is reduced to only its root which will 
either be Id or Fail (a successful strategy or a failed one, respectively). The user will then have a 
visual representation of the final state of the graph as well as a step by step trace of the strategy 
applied. 

4 Applications 

4.1 Arithmetic programs with Interaction Nets 

In term rewriting systems with a finite signature, natural numbers are often represented using 
two function symbols: S and 0. Then the number n is represented by a term S(S(. . . S(0) . . .) with 
n occurrences of S. This representation is inefficient, but in [20| it is shown that using Interaction 
Nets we can implement efficiently arithmetic operations on integers, with a finite signature, by 
representing a number z in the form of a difference list p-cj. The I agent is used as head of a 
number, and holds two lists of S agents: a left list containing p and a right list containing q; see 
Figure |3]for an example of the number 1 represented as 4 - 3. We also note that there are infinite 
representations for each number in this way: 1=4-3 = 6- 5 = 7- 6 = ... 

The open rule given in Figure [3] extracts both lists from a number so that they can be used 
for arithmetic operations. If two lists are put head to head, the reduce rule will eventually 
return a single list containing the absolute value of the difference of the lists. The right-hand 
sides of these two rules are depicted as wires, that is, when the rule reduce is applied, the ports 
connected to the S agents being reduced will be connected together, and similarly for the open 
rule. The negate rule switches the left and right list of a number, giving us its negative. The 
negate rule has its entire right hand side in its subgraph M, so if P is initially the whole graph 
then no matter which of these three rules we apply, P will always be the entire graph. 

Using these three rules we can model Addition, Negation and Subtraction, as seen in Figure|4] 
If we liken the size of a graph to memory space, we could then prioritise the reduce rule so that 
the graph is always kept at its smallest. A useful strategy to design would then be: 
ArithStrategy: repeat, (repeat, (reduce) ;Try (negate) ;Try (open)) 
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Figure 3: An example number and the open, reduce and negate rules. 

Here, we apply first the rule reduce as much as possible, to simplify the representation of the 
numbers, followed by applications of negate and open to perform the arithmetic operations. 

4.2 Von Koch Fractal 

To draw a Von Koch Fractal (see Figure|5|, we only need one agent type and one rule. Our initial 
graph is a triangle and has one (and only one) of its nodes in P. We define a rule vonKoch of type 
(L => R)m (see VFK in Figure [5]) such that M contains the right-most agent from the right-hand 
side of the rule. This means that after each application of the rule vonKoch the subgraph P is 
updated to restrict the next application of rules to the neighbouring segment. Visually, our rule 
will travel round the triangle, segment by segment, gradually creating a more complex fractal 
after each round trip. 

In Figure[6j we can see three successive applications of vonKoch. Agents drawn with dashed 
lines are agents that are in P. The VKF strategy used is simply: 

whi\e(vonKoch)do(vonKoch)mm(0)max(m) 
where m is the number of iterations required. 

Without the notion of position in the strategy language, the application of the VKF rule 
would have been random and the fractal generated would not necessarily be balanced. The 
strategy language allows us to define for each rewrite rule the nodes in the right-hand side that 
will become part of the position subgraph. The ability to update positions directly is exploited 
in this example to obtain a simple and concise program that goes round the triangle creating 
the fractal in a balanced way. 

For this example, it is important that the shape and layout of the right hand side of the rules 
is preserved during the rewriting step to ensure the proper shape of the fractal. In PORGY the 
user can specify for each rule whether the shape of the right hand side is preserved or not. 
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Figure 6: The Von Koch Fractal. 



4.3 Game example: Pacman 

To simulate a game of pac-man, we use the initial graph in Figure [7] with the five types of nodes 
depicted. We assume all nodes in this system to have four ports each, one for each direction. 
For visual simplicity we will not draw any free ports or ports whose state does not affect a 
rewrite rule. 

The rewrite rules for pac-man can be found in Figure [8] These rules, with the help of a 
strategy, will help simulate a basic behavior for pac-man. Pac-man's first instinct will be to flee 
any nearby ghosts (rules fleela, fleet b, fleela and fleelb). If pac-man is not near any ghosts he 
will then seek out pac-dots (rule getPacDot) and then if not near any pac-dots, he will proceed 
to explore the level (rule explore). 

The strategy for controlling pac-man is as follows: 

• pacAI: if(nearGhostl orelse nearGhostl) then (Flee) else (Move) 

• Flee: \i(fleela orelse fleelb) then (fleela orelse fleelb) else (Try (fleela orelse fleelb)) 

• Move: if(getPacDot) then (getPacDot) else (Try (explore)) 

The rewrite rules for the ghosts can be found in Figure [8] Like for pac-mac, these rules and 
a set of strategies will help simulate the behaviour of the ghosts. A ghost's first priority is to 
eat pac-man (rules killl and kill2). If pac-man is not nearby, then a ghost will try move to a 
space with no pac-dots (rules moveEl and moveEl) since following empty spaces should lead 
the ghost to pac-man. If a ghost can only move to a space with a pac-dot then do so (rules 
movePl and movePl). 

The strategy for controlling ghosts is as follows: 

• ghostAI: if(£:z7/l orelse killl) then (killl orelse killl) else (gMove) 
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Figure 7: The pac-man playing field. 

• gMove: \i(moveE\ orelse moveEl) then (moveEl orelse moveEl) else (Try(movePl orelse 
movePl)) 

The overall strategy called gameLoop that controls the game is as follows: We must first check 
that pac-man has not been eaten (by checking for the existence of a node of type End). We then 
call pacAI followed by ghost AI for each ghost (we do this by adding pacman and all ghosts to 
P at the start of each game loop using Property(Y,G) and making sure all the rules that involve 
ghosts have an empty M. This means every time a ghost performs an action, which removes the 
ghost from P, it cannot perform another one till the next game loop). 

• gameLoop: repeat* (Property( Y,G);if (fsGameOz;er)then(Fflz7)else(pflcAJ;repeat* (ghost AI) ) 

• Y is: type=="ghost" or "pac-man" or "End" 

As we can see, a basic pac-man game does not require many agents and just six relatively 
simple strategies are sufficient to model it using our language. 

Adding a scoring system would be trivial: each time pac-man eats a pellet, a point agent 
would be created and added to a list of points which can then be counted at the end of a game. 

If there is more than one possible application of a rule, the implementation will pick one of 
the possibilities at random. This will create a different game each time. 

4.4 Labyrinth 

We will now give a program to find a path in a labyrinth. The labyrinth is represented as a 
graph built out of Labyrinth agents, as shown in Figure |9j where Labyrinth agents are depicted 
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Figure 8: The set of rules to control pac-man (left) and to control the ghosts (right). 

as empty circles and exits are represented with an End agent. The initial located graph in this 
example has a Father agent connected to the start of the maze. 

A Labyrinth agent has five ports, one for each cardinal direction North, East, South and West 
and a Father port, where a Father agent can attach to (see Figure [lOj. The End agent has the 
same ports as a Labyrinth agent but will react differently when a Father agent is connected to it. 
We will also have a Visited agent, which has the same ports as a Labyrinth agent but like the End 
agent, will react differently when a Father agent connects to it. Lastly we have a PATH agent 
which has the same ports as the Labyrinth agent and will be used to replace Labyrinth agents so 
that a visible path will be drawn from the start to the exit of the labyrinth. 

For the sake of clarity, in the following diagrams the four directional ports will not be 
labelled but will be drawn in the standard orientation on the agents. In the rules, a white port 
means that the port must be connected, a crossed port must be free and a black port means 
either connected or free. 

A Father agent has a Position port and a List port. The Position port connects to a Labyrinth 
agent and the List port will connect to a list of Direction agents (representing the path followed 
so far). We have four Direction agents N ,E,S and W that each have two ports: a Next and a Prev 
port. We will also need a Drawer agent (with the same ports as a Father agent) that will travel 
back to the start of the labyrinth, following a list of Directions and replacing Labyrinth agents 
with PATH agents. 

Lastly, we have some management agents: two copy agents (cpl and cp3) and a delete agent 
named e. The copy agents take a list of directions and duplicate {cpl) or triplicate (cp3) it. The 



Fernandez and Namet 



13 




Figure 9: An example of a labyrinth. 



e agent takes a list and deletes it. The rewrite rules for cpl can be found in Figure 12 (the cp3 



rules are similar but produce three copies) and the rewrite rules for e in Figure 13 



The program consists of the strategy expression LabStrat described below, and a located 
graph representing the labyrinth, where the only node in the initial subgraph P is the Father 
agent marking the starting point in the labyrinth. The strategy has two main parts, which we 
call Step 1 and Step 2. Step 1 attempts to find a path to the exit of the labyrinth, by moving 
the starting Father until a Father agent positions itself onto the End agent. If a Father agent is 
positioned onto an End agent, a path was found and the program will move onto the Step 2. 
When a Father agent moves to a new position, it changes the Labyrinth agent it moved from into 
a Visited agent. This will ensure the Father agent never backtracks. 

The strategy will start by checking if a Father agent is connected to four Labyrinth or End 
agents that have their Father port free (rule splitA in Figure [l4j a special case of when the starting 
Father is put on such a Labyrinth agent). This rule will remove the Father agent and create 
four new Father agents for each of the four positions and give each one of the new Fathers a 
corresponding Direction agent (to remember the step done). 

If splitA cannot be applied, the strategy will try to apply one of the four splits rules splitSa, 
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Figure 10: A Labyrinth agent, End agent and Visited agent. 
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Figure 11: A Pather agent and the four Direction agents. 



split3b, split3c or split3d. This rule deletes the original Pather agent and creates three new Pather 
agents, adding a corresponding Direction agent to each of their lists, and copying the original 



Pather agent's list onto the end of the new Pather agents' lists. See Figure 15 for the split3a rule 
(the other three split3 rules are similar, taking into account the remaining combinations). 

If none of the split3 rules can be applied, the strategy then tries all six of the splitl rules and 
if none of the splitl rules can be applied, it tries one of the four splitl rules. These rules do the 
same thing as the split3 rules but only split to two and one Labyrinth agents respectively. See 



Figure 16 for splitla and splitla. 

We need to apply the split rules in this specific order or a possible split might be missed. For 
example, splitla might be applicable somewhere where split3a is also applicable but by applying 
splitla first we would not then explore the labyrinth to the West or South. This could lead to 
ending up with a longer path to the exit or in the worst case not finding the exit at all. 

All split rules have an empty M subgraph. This will allow the strategy to move each Pather 
at most once per iteration. The strategy will do this and then use Property(p,G) to add all the 
Fathers back to P and then start over again. This ensures that no Pather is given priority and is 
needed to find the shortest path (as explained further down). 

While trying to apply the split rules in that specific order, the strategy will constantly check 
if the found rule (in Figure [17|) is applicable. If it is, it moves onto Step 2: drawing the path. If 
the End node is not reachable from the starting point, the program will not terminate. 



Step 2 checks if the done rule (Figure 17 ) is applicable and if it is not it will attempt to apply 



the four draw rules draivN, drawE, drawS and drawW. See Figure 17 for the draivN rule; the other 
three draw rules are similar and cater to a different direction each. 
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Figure 12: The set of rules for cp2. 

If the done rule is applicable, the program will terminate and our labyrinth will have the 
shortest path to the exit drawn on it. 

• LabStrat: Stepl ; Step! 

• Stepl: while(Not(/otm£f))do(repeat»(SfeplSpZz'r); Property(Y / G))min(0)max(-l); found 

• Y is: type=="Pather" 

• SteplSplit: splits orelse split3a orelse split3b orelse split3c orelse split3d orelse splitla orelse 
splitZb orelse splitlc orelse splitld orelse splitle orelse splitlf orelse splitla orelse splitlb 
orelse splitlc orelse splitld 

• Step2: whi\e(Not(done))do(drazvN orelse drawE orelse drawS orelse drawW)min(0)max(-l); 
done 

Since Labyrinth agents are changed to Visited agents when a Father moves from them, if 
a branching occurs in the labyrinth that later reconnects (as seen at the lower middle Figure 
|9| the branch with the shortest path will be picked (remembering that each Father can only 
take one step at most during each iteration so the Father in the shortest branch will get to the 
reconnecting Labyrinth node first). 

Branching that reconnects will cause stuck Fathers. When the Father from the quickest 
branch gets to the reconnecting Labyrinth node, it will split and go to the slowest branch. That 
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Figure 13: The set of rules for e. 




Figure 14: The splits rule, a is a Labyrinth or End agent. 

newly split Father will eventually meet the original Father of that branch (going the other way). 
These two Father agents will be positioned in two adjacent Labyrinth agents but won't be able to 
move and remain stuck there. We could extend our graph program by creating a set of rules to 
eliminate these stuck Father agents, using the e agent. This is mainly an aesthetic improvement 
since the stuck Father agents will not affect the functionality of the program. 

5 Related Work: Graph Rewriting Tools 

Several tools are available to edit graphs, and some of them allow users to model graph 
transformations. Below we review some of the systems that share some goals with PORGY. 

GROOVE |26j is centered around the use of simple graphs for modeling the design-time, 
compile-time, and run-time structure of object-oriented systems. Visualisation is not the main 
objective, and after each rewrite step the user must update the layout of the graph by hand. 
GROOVE permits to control the application of rules, via a control language with sequence, 
loop, random choice, try()else() and simple (non recursive) function calls. These are similar to 
PORGY's constructs, but GROOVE'S language does not include the notion of position; thus, it 
is not possible to specify directly a position for the application of rules. 

The Fujaba Il23l Tool Suite is an Open Source CASE tool providing developers with support 
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Figure 15: The split3a rule, a is a Labyrinth or End agent. 
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Figure 16: The splitla and splitla rule, a is a Labyrinth or End agent. 



for model-based software engineering and re-engineering. Fujaba has a basic strategy language, 
including conditionals, sequence and method calls. There is no parallelism, and again one of 
the main differences with PORGY is that Fujaba does not include a notion of location to guide 
the rule application. 

AGG [14] is a rule based visual language supporting an algebraic approach to graph trans- 
formation. It aims at the specification and prototypical implementation of applications with 
complex graph-structured data. The application of rules can be controlled by defining layers 
and then iterating through and across layers. Again, there is no notion of position and there is 
no control on the search for redexes. 

PROGRES [28] offers an executable specification language based on graph rewriting systems 
(graph grammars). The aim is to combine EER-like and UML-like class diagrams for the 
definition of complex object structures with graph rewrite rules for the definition of operations 
on these structures. PROGRES allows users to define the way rules are applied (it includes 
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Figure 17: The found, done and drazvN rules. 



non-deterministic constructs, sequence, conditional and looping) but it does not allow users to 
specify the position where the rule is applied. It is a very expressive language and includes a 
tracing functionality through backtracking. 

GrGen.NET [17] is a programming tool for graph transformation designed to ease the trans- 
formation of complex graph structured data as required in model transformation, computer 
linguistics, or modern compiler construction, for example. It is comparable to other program- 
ming tools like parser generators which ease the task of formal language recognition. 

GP ||25ll is a rule-based, non-deterministic programming language. Programs are defined 
by sets of graph rewriting rules and a textual expression that describes the way in which rules 
should be applied to a given graph. The simplest expression is a set of rules, and this means 
that any of the rules can be applied to rewrite the graph. The language has three main control 
constructs: sequence, repetition and conditional (if-then-else), and it has been shown to be 
complete. It uses a built-in Prolog-like backtracking technique (users cannot easily handle the 
derivation tree or change the backtracking algorithm). 

GReAT (Graph Rewriting and Transformation) (51 is a tool for building model transforma- 
tion tools. Rule execution is sequential and there are conditional and looping structures. 

PORGY and its strategy language allow a higher expressive power with its focus on position. 
Strategies are not limited to picking random applications but can travel through the graph in a 
dynamic and strategic manner to apply rules and sub-strategies. PORGY has also a strong focus 
on visualisation and scale, thanks to the TULIP back-end which can handle large graphs with 
millions of elements and comes with powerful visualization and interaction features. Some of 



Fernandez and Namet 



19 



Tulip's built-in functionalities, such as selecting a node in the trace for highlighting its "lifetime" 
within the trace, give the user an immediate visual feedback. 

6 Conclusion and Future Work 

The strategy language defined in this paper is part of the PORGY [1] system, which is an 
environment that allows users to define graphs and graph transformation rules. PORGY is im- 
plemented using the TULIP platform, for the visualisation of graphs and graph transformation 
rules. PORGY provides also tools to visualise traces of rewriting, and the strategy language is 
used in particular to guide the construction of the traces. 

Although PORGY and its strategy language were implemented specifically to work with 
port graphs (and interaction nets in particular), the strategy language could be applied to other 
graph formalisms (e.g., term graphs). This is a direction for future work. Verification and 
debugging tools for avoiding conflicting rules or non-termination are also planned for future 
work. The PORGY strategy language is not minimal and finding a set of minimal constructs 
will also be a subject for future work. 

Acknowledgements We are grateful to the members of the PORGY team, and in particular to 
Helene Kirchner, for many inspiring discussions on the topics of this paper. 
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